As known in the art, Instant Messaging (IM) services such as AIM and ICQ, amongst others, allow a user to maintain a contact list (or buddy list) comprising the destination addresses of other users they may wish to interact with. A user is alerted when another user matching one of the entries in his contact list goes online, and a real-time exchange of messages can take place with any of these users provided they are currently online (present) and not otherwise busy. In one embodiment of an IM service, initiating sending a message to a user opens up a small window, or dialog box, through which both users can interact in real-time by typing in text.
IM services, as are the majority of open distributed applications, are often based on a client-server architecture, where a large number of clients, typically in the form of software modules located on devices being used by individual users (such as a personal computer, PDA or the like) communicate with one or more centralised servers. The server typically responds only to requests for services which are initiated by the client. In this regard, the client will initiate establishment of a (logical) communications channel with the server by “logging on”, and once established bidirectional communications can take place between client and server. In particular, once a communications channel has been established between the server and a client, the channel can be taken advantage of for the transfer of relevant IM service information. As stated above, one type of information provided and managed by IM services is contact lists.
For IM services which are implemented using personal computers and high speed wired or wireless networks, arbitrarily long contact lists may be used without any significant impact on system performance. Additionally, the attributes (or status) of individual entries in the contact list typically change over time as users come online or go offline, become engaged with other users, etc. In order to support the display of arbitrarily long contact lists and maintain currency of the displayed information, sizeable display capabilities, large available memory and frequent signaling are required. In wireless networks, where the constraints on device capabilities and network capacity are more severe, storing and maintaining status information for arbitrarily large lists of destination addresses is much more challenging.
IM services typically additionally allow a user to group contacts into smaller subsets of lists (co-workers, buddies, etc.) for easier manipulation. Existing wireless mobile instant messaging systems allow the user to create a specific contact list for usage on a mobile device. For example, U.S. Pat. No. 6,714,793 for a “method and system for instant messaging across wireless networks and a public data network”, the entire contents of which is incorporated herein by reference, describes a communications system for sending a message from a wireless device over a wireless communication network. The disclosed method allows for use of destination addresses that were previously stored on the device. The method also allows the user to add new destination addresses via the device handset, but does not allow additional addresses to be collected from the communications network.
Similarly, the Open Mobile Alliance (OMA) Wireless Village Standard allows for the mobile device to request the network to supply a contact list of destinations addresses using the ListManageRequest primitive. However, no mechanism is provided for limiting the size of a contact list, for example by requesting less than the complete contact list. Furthermore, there is no mechanism for allowing the server to interactively modify the content of a contact list located at a client device during a session. The Wireless Village Standard allows for the user to modify the contact list content using the ListManageRequest, but this again does not allow for dynamic management on the part of the server to modify the content of the contact list.
Mobile devices usually contain an address book (AB), where the user may enter phone numbers of contacts. This address book may also include additional fields such as email addresses. However, these address books do not include fields for destination addresses for instant messaging contacts. As a result, there is no mechanism for associating instant messaging destination addresses with other identities in the mobile device (e.g. with the information in the device address book).